Wide area storage localization system

ABSTRACT

A system is described for facilitating retrieval of information from various sites to a secondary site using mirroring or other data replication software. At the secondary site using a proxy system, an operator may retrieve data from the secondary systems mirrored to the site. The system is particularly applicable to combining disparate types of remotely situated databases.

CROSS-REFERENCES TO RELATED APPLICATIONS

[0001] NOT APPLICABLE

STATEMENT AS TO RIGHTS TO INVENTIONS MADE UNDER FEDERALLY SPONSOREDRESEARCH OR DEVELOPMENT

[0002] NOT APPLICABLE

REFERENCE TO A “SEQUENCE LISTING,” A TABLE, OR A COMPUTER PROGRAMLISTING APPENDIX SUBMITTED ON A COMPACT DISK.

[0003] NOT APPLICABLE

BACKGROUND OF THE INVENTION

[0004] This invention relates to data storage systems, and in particularto systems which allow retrieval of database information.

[0005] Hardware and software vendors, working in conjunction withcorporations and other entities around the world, have developedtechnology for intranet systems which allow a company to share itsinformation among its employees, even though those employees are locatedin different offices. In such systems individual branches maintainservers which dispense information to the employees at that office. Toobtain information from other offices, the client terminal searchesother servers to obtain the desired information. Such a client-serverarchitecture model requires the client to access remote servers eachtime the search process occurs. This means that every transactionnecessitates a network delay time to receive a reply from the remotesite. The network latency caused by distance and the lack of bandwidthoften found between the remote sites makes it difficult to implement anintranet system on a worldwide basis.

[0006] Another approach which allows sharing of data and knowledge in adifferent manner is XML technology. XML theoretically makes it possibleto integrate various repositories of data, even if each differentrepository is managed by a different organization or a different domain.While this has superficial appeal, integration of the data at this levellacks flexibility because all repositories that are integrated must beformatted with the same data structures in a static Document TypeDefinition (“DTD”). Operators at each site who construct the repositorydata must follow the DTD, precluding them from enhancing their datastructures for a particular need at that site, and thereby limitingtheir flexibility. Similar approach has been to employ data leveldatabase integration. This, however, has also proved difficult for thesame reason. The databases to be integrated must have common tablespaces that are consistently defined with respect to each other.

[0007] In yet another approach, known as the Oracle Transparent Gateway(“OTG”), the databases at the different locations that are integratedare integrated virtually. The databases do not actually integrate datafrom each site, but client requests to the databases are split andforwarded on the multiple database servers in the proper message format.This allows the client to access the multiple servers as if they wereaccessing a single database. Each database, however, remains remote,subject to the difficulties of delay, etc., described above. Prior artdescribing each of these approaches include: (1) “Enterprise InformationIntegration,” published by MetaMatrix, Inc. (2001); (2) “Hitachi DataSystems 9900 and 7700E—Guideline for Oracle Database for Backup andRecovery,” published by Hitachi, Ltd. (January 2001); (3) “Guidelinesfor Using Snapshot Storage Systems for Oracle Databases,” by NabilOsorio, et al., published by Oracle (August 2000); and (4) “MicrosoftSQL Server on Windows NT Administrator's Guide,” published by Oracle(April 2000).

[0008] Accordingly, a need exists for the sharing of data from remotesites without need of conforming data structures and without the delaysinherent in repeated querying over long distances.

BRIEF SUMMARY OF THE INVENTION

[0009] This invention provides a storage-oriented database localizationsystem. The system assumes a circumstance in which there are multipleremote sites, and each site has its own local database. According to apreferred embodiment, the system localizes all, or a part of, the datafrom each remote site into a central site. Unlike the prior solutionsdescribed above, this system does not integrate the databases at thedata level, but rather, it replicates the stored data itself from theremote sites to the central site, so that copies of the database fromeach remote site are present at the central site. Providing the featuresin this manner solves the problem of flexibility of data integration andeliminates the delays of the systems described in the references above.

[0010] At the central site a database proxy server provides a gateway toeach of the multiple replicas. Data access requests issued by operatorat the central site are split at this proxy, made into multiple replicasand sent out to the copies of the remote databases. (The copies are alsoat the central site.) Replies from each replica are then merged at theproxy server before being returned to the operator. This featureprovides flexibility and speed in accessing multiple stored databases.

[0011] The invention relies upon the replication mechanism now oftenavailable in storage systems. Storage equipment now typically includes afunction which provides the capability of mirroring data between remotesites, without need of server CPU control. The use of the mirroringfunction enables mirroring data over long distances on a worldwidescale. The storage equipment associated with such mirroring operationsmakes it possible to guarantee the write order in the communicationbetween a primary and a secondary site, and to even continuously providedisk mirroring over long distances.

[0012] Another feature of the invention is a snapshot controller. Thesnapshot controller controls a write process at the site which is toreceive mirrored data from another site. The snapshot controllermonitors the cache data as it arrives and checks to assure proper writeorder. It then allows the cached data to be written into disk space whenthe write order has been verified. Thus, this mechanism enablescontinuous data transfer without impacting the information retrievalsystem, thereby minimizing delays. The transfer of data between the twosites can be synchronous or asynchronous, or a combination thereof.

[0013] In a preferred embodiment of the invention, a system forfacilitating retrieval of information in which a first system storesfirst data to first location and the second system stores second data toa second location includes several aspects. These aspects include aterminal connected to retrieve data from the first system, and areplication software program for copying data from the second system tothe first system. A proxy system operating at the first location enablesa user of the terminal to retrieve data from the second system whichdata have been copied to the first system from the second system.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014]FIG. 1 is a diagram illustrating an overall wide area storagelocalization system;

[0015]FIG. 2 is a block diagram of a storage system hardware structure;

[0016]FIG. 3 is a more detailed example of storage system architecture;

[0017]FIG. 4 is an example of status information for disk mirroring at aprimary site;

[0018]FIG. 5 is an example of status information for disk mirroring at asecondary site;

[0019]FIG. 6 illustrates the transfer of data from a primary to asecondary system;

[0020]FIG. 7 is a flowchart for initializing a disk pair;

[0021]FIG. 8 is a flowchart of data input at a primary storage system;

[0022]FIG. 9 is a flowchart of a mirroring data transfer;

[0023]FIG. 10 is a flowchart illustrating a procedure for writing datainto local disk space at a secondary site;

[0024]FIG. 11 is a diagram of a database proxy hardware structure;

[0025]FIG. 12 is a more detailed example of a database proxyarchitecture;

[0026]FIG. 13 is a flowchart illustrating the database proxy operation;

[0027]FIG. 14 is an example of tracking database access information;

[0028]FIG. 15 is a flowchart illustrating the search of multipledatabases by a database proxy server; and

[0029]FIG. 16 is an example of how multiple data retrievals are mergedat a database proxy server.

DETAILED DESCRIPTION OF THE INVENTION

[0030]FIG. 1 is a block diagram providing an overview of a wide areastorage localization system. Illustrated in FIG. 1 are three primarysites A105, B106 and C107, and one secondary site 100. Typically, sitesA, B and C will be remotely located from each other and from secondarysite 100. At each of the primary sites, data is managed locally by anoperator. In accordance with the invention, the data stored at eachprimary site is replicated to the secondary site 100. Typically, thisdata replication operation occurs over a network, and will be performedseparately for each of sites A105, B106 and C107.

[0031] The secondary site 100, collects all or a portion of the datafrom the primary sites and stores it, as indicated by stored datarepresentation 103. A database proxy 101 provides access to the data103. Data access requests from operators 102 are split by the proxy 101and forwarded onto local database servers 104, each of which manageslocal replicas 103. The DB proxy 101 merges replies from the multipleservers before it returns a reply to the operator. This enables theoperator to access data from the multiple databases using a singlerequest.

[0032] The data replication process between the primary sites and thesecondary site is preferably performed using conventional datareplication technology, commonly known as volume mirroring. Themirroring is ideal to continuously maintain an instant replica at thesecondary site; however, “ftp” data transfer executed once per week willalso help operators at the secondary site. This is well known anddescribed in some of the prior art cited herein. See, e.g., “HitachiData Systems 9900 and 7700E—Guideline for Oracle Database for Backup andRecovery,” published by Hitachi, Ltd. (January 2001). The database proxyserver 104 are well known, for example as described in “Microsoft SQLServer on Windows NT Administrator's Guide,” published by Oracle (April2000).

[0033]FIG. 2 is a block diagram illustrating the hardware structure of astorage system. The storage system depicted in FIG. 2 can be employedfor storage of data in each of the primary and secondary sites shown inFIG. 1, or other well known systems may be used. As shown in FIG. 2 thestorage system hardware structure includes storage space 205, forexample, comprising an array of hard disk drives or other well knownmedia. The storage media is connected to a bus which also includes a CPU202, a cache memory 203, and a network interface 204 to interface thesystem to the bus and the network. The system also includes input andoutput devices 206 and 207. Disk I/F chip (or system) 201 controls inputand output operations from the storage space 205. Although theconfiguration for the storage system depicted in FIG. 2 is relativelyminimal, storage systems such as depicted there can be large andelaborate.

[0034]FIG. 3 is a diagram illustrating in more detail the storage systemarchitecture. On the left portion of FIG. 3 is illustrated a primarystorage system, for example such as the site A storage system 105 inFIG. 1. On the right side of FIG. 3 is illustrated a secondary storagesystem, such as depicted as system 100 in FIG. 1. The two systemsinclude almost identical components, with the exception that in theillustrated embodiment secondary storage system 302 includes a snapshotcontroller 303 discussed below. The storage systems each include diskspace 205, access to which is controlled by disk adapter 305. The diskadapter operates under control of an I/O controller 304 and a mirrormanager 306. It accepts data from cache memory 203. A disk statusinitialization program 309 and status information 308 are also coupledto the mirror manager 306. The mirror manager 306, operating through alink adapter 307, communicates with the link adapter in other storagesystems, such as depicted in FIG. 3, to exchange data. The programsinvolved in control and operation of the storage system are loaded intomemory space 203 during operation. The disk spaces 205 are organized asdisk volumes.

[0035] The host 310 operates the storage system through the I/Ocontroller 304. The I/O controller program 310 issues a read request tothe disk adapter 305 when it receives a read request from the host I/Oprogram 311. If a write request is issued by the host program 311, thencontroller 304 causes the data for that write to be stored in cachememory 203, then issues the write request to the disk adapter 305.

[0036] The disk adapter 305 and its software manage data loaded from thedisk volumes 205 or to the stored into the disk volumes 205. If the diskadapter 305 retrieves data from disk space 205 in response to a readrequest, it also stores that in cache memory 203. When disk mirroring isconfigured at each site, the disk adapter 305 asks for, and awaitspermission, to be acknowledged by the mirror manager program 306 beforebeginning writing of disk volumes 205.

[0037] The mirror manager program 306A manages data replication betweenthe primary and secondary sites. The software in the mirror manager 306Aat the primary site 301 sends data that is to be written into local diskspace 205A to the secondary storage system 302 through the link adapter307A. The transferred data are then received by the link adapter 307B atthe secondary site 302 and are stored into the cache memory 203A. Themirror manager program 306B at the secondary storage system 302 receivesthe cached data and issues an instruction to the snapshot controllerprogram 303 to check the consistency of the data. Assuming that it isconsistent, the mirror manager program 306B at the secondary site 302instructs the write process to the disk adapter 305B.

[0038] The link adapter programs 307A and 307B manage communicationbetween the primary and second storage systems. Preferably, the softwareincludes a network interface device driver and typical well knownprotocol programs. The link adapter program 307 loads data from thecache memory 203A on the primary site, and stores it into the cachememory 203B at the secondary site when it receives it. The status of themirroring operation is stored in status information 308, which itinitialized by program 309.

[0039]FIG. 4 is a diagram which provides an example of the status of thedisk mirroring operation at the primary site, while FIG. 5 is an exampleillustrating the status of disk mirroring at the secondary site. Forthis example, assume that all replications are based on disk volumes asthe unit of storage space employed. The tables in FIGS. 4 and 5 list thedisk volume information on each row. The table 308A in FIG. 4illustrates the information for the primary system. For each volume thetable defines the raw device address 401, the mount point 402, thevolume size 403, the synchronization mode 404, and a remote link address405. Device address, mount point and size specify volume identificationinformation as assigned by the operating system. These are typicallydefined in the “/etc/fstab” file in Unix-based systems. Thesynchronization mode is defined as to synchronous or asynchronous basedupon the replication mode. The remote link address mode 405 defines thetarget address assigned at the secondary site.

[0040]FIG. 5 in table 308B illustrates the same parameters for mirroreddisk status information for the secondary site. It, however, alsoincludes the remote mount point 506. The remote mount point defines thepair volume between the primary and secondary sites.

[0041]FIG. 6 is a diagram illustrating an example of transferring datafrom the primary storage system 301 to the secondary storage system 302.The exact mechanism depends upon the details of storage systemfunctionality described above; however, FIG. 6 illustrates a minimumspecification. In FIG. 6 an asynchronous data transfer is provided as anexample, with source 603 and destination address 604 defined as IPaddresses. These addresses will depend upon the communication method, soother addresses may be used, for example, worldwide name in the case offiber channel communications. The disk space information 601 shown inFIG. 6 identifies the target file name. The write order information 602defines the sequence of data writing. This write order field is usedbecause the transferred data will almost always be split into multipleparts during transfer. In circumstances involving long distancecommunication, later parts can pass earlier parts in the network. Asshown in FIG. 6, the data payload has appended to it data fieldsrepresenting the disk space 601, the write order 602, the source address603 and the destination address 604. As described in conjunction FIG. 3,the data is transferred between the link adapters of the primary andsecond storage systems.

[0042]FIG. 7 is a flowchart illustrating initialization of a disk pair.This operation is carried out by the mirror manager 306 (see FIG. 3). Inoperation, the mirror manager 306 on both the primary system 301 and thesecondary system 302 exchange information through the link adapter 307to complete the initialization. First, at steps 701 and 704, thesesystems 301 and 302 configure each local data link address. For example,the system managers will assign a unique IP address for each networkinterface device. After that, at step 702 the primary site sets up thedisk space configuration that should be mirrored or paired. Next, atstep 703 the primary system 301 notifies the local mirrored disk statusto the secondary system which receives the information at step 705. Whenthe secondary system receives the information sent from the primarysystem at step 705, the secondary system configures the local disk space(step 706). Next, at step 707 the secondary storage system sends thelocal disk status information to the primary system, where it isreceived at step 708. When the primary system receives the information708, it configures the synchronization mode for each disk space 709 asdescribed in FIG. 6. Then, at step 710, it sends the synchronizationmode configuration information to the secondary system where it isreceived at step 711. The secondary system updates the local mirroreddisk status information at that time. Using these steps, both theprimary and the second storage systems establish consistent mirroreddisk status information at each location.

[0043]FIG. 8 is a flowchart illustrating operation of the primarystorage system when it receives instructions from the host. Therelationship of the host and the primary storage system are shown inFIG. 3. As shown in FIG. 8, following the initialization processdescribed in FIG. 7, the primary storage system, at step 801, beginsreceiving input information from the host 310. When the storage systemreceives input information, it is supplied to the I/O controller 304Awhich stores it into the cache memory 203A (see FIG. 3). The diskadapter 305A is then notified. It awaits permission to be issued frommirror manager 306A before it processes the disk write into the localdisk volumes 205A. The mirror manager 306A then forwards the replicationdata to the secondary system 302. This is shown by step 802 in FIG. 8.

[0044] Next, as shown by step 803, a determination is made of thesynchronization mode. This determination is based upon the mirrored diskstatus information 308A (see FIG. 3). If the synchronization mode is setto “asynchronous,” control proceeds to step 805. On the other hand, ifit is set to “synchrous,” as shown by step 804 in FIG. 8, the systemwill wait for an acknowledgment message 804 from the secondary systemnotifying the primary system that the replication has been completedsuccessfully. In either mode, as shown by step 805, ultimately anacknowledgment signal is returned to the host to inform the host thatthe data was received successfully.

[0045] The actual writing of information onto the storage volumes in theprimary system is performed using well known technology, for example asdescribed in the reference “Hitachi Data Systems 9900 and7700E—Guideline for Oracle Database for Backup and Recovery,” publishedby Hitachi, Ltd. (January 2001). This includes carrying out the writingof cache data into the proper disk space with the proper timingaccording to well known write processes.

[0046]FIG. 9 is a flowchart illustrating a data transfer from theprimary to the secondary system as embodied in step 802 of FIG. 8. Asshown in FIG. 9, the first step 901 is for the mirror manager 306A (seeFIG. 3) to command the link adapter 307A to send the data. The mirrormanager 306A then notifies the target address 604 and the disk space 601configured in the mirrored disk status information 308A. The linkadapter 307A then loads the data from the cache memory 302A, as shown atstep 902. It also sends the data to the target address in the formatdescribed in conjunction with FIG. 6. This operation is shown in step903 in FIG. 9. As shown at step 904 in FIG. 9, the link adapter at 307Breceives the data transferred from the primary link adapter 307A. Then,as shown in step 905, it stores that information into the cache memory.

[0047]FIG. 10 is a flowchart illustrating the data writing process inwhich data is written into the local disk space at the secondary site.The process begins at step 1001 with the snapshot controller 303scanning the data stored the cache memory 302B. The snapshot controller303 monitors the write order to assure consistency. As shown by step1002, if the write order is consistent, i.e., the data to be written isto be written next in order following the data previously written, thesnapshot controller notifies the mirror manager 306B of this. This isshown at step 1003 in FIG. 10. As shown by step 1004, in response, themirror manager 306B issues a command to the disk adapter 305B so thatthe disk adapter 305B processes the data write into the proper diskspaces. This operation is shown in step 1005. In response, as shown instep 1006, the mirror manager returns an acknowledgment messageindicating that the data replication has been successful.

[0048] As described above, one benefit of the invention is its abilityto provide an operator with access to multiple databases which have beenreplicated at a particular site. The DB proxy hardware server forproviding this access is shown in block form in FIG. 11. As shown inFIG. 11, the hardware includes a disk, input and output devices, a CPU,a cache memory, and a network interface. In some implementations of theinvention, the DB proxy hardware consists of a general purpose personalcomputer.

[0049]FIG. 12 is a diagram illustrating the DB proxy architecture. FIG.12 is a more detailed version of the diagram 100 shown as a part ofFIG. 1. Three storage systems 103A, 103B and 103C are shown in FIG. 12.Each includes an I/O controller coupled to a server 104A, 104B and 104C,respectively. The storage systems shown in FIG. 12 are the replicasmirrored from remote storage systems 106 (see FIG. 1). The server hosts104 are the hosts that accept the I/O commands. The client host 1201 isthe host that provides an interface for the operators 102 at secondarysite 100. The database proxy 101 provides data search functions acrossthe multiple server hosts 104A, 104B, and 104C. As shown in FIG. 12,each server host 104 includes a host I/O program 311 and a datamanagement program 1203. The host I/O program 311 is the same as thatdescribed in FIG. 3. The data management program 1203 is a program thataccepts search requests from external hosts and processes data searchesin response to those requests.

[0050] The client host 1201 includes a www client 1202 which isimplemented by a general web browser issuing http requests and receivingHTML contents in http messages. In FIG. 12 the client is shown asissuing requests in http; however, many other types of clients may beemployed in conjunction with the invention. For example, a typical SQLclient can issue data search requests in SQL messages to the proxyserver 101 if an SQL client it employed, then server 1204 will be an SQLmessage interface instead of a www server interface. In the preferredembodiment, the proxy server 101 includes a traditional web serverprogram that accepts http requests from external hosts and return thecontents in http messages. This server program 1204 is used to providean interface to hosts.

[0051] The client I/O program 1205 in proxy server 101 is a program thatcontrols the communications between the proxy server and the client host1201. This I/O program 1205 can be implemented in a typical CGI as abackend portion of the www server 1204. The database search program 1206is a program that retrieves data from databases as requested by clienthost 1201. Program 1206 can be a well known database software whichdivides client requests and forwards them to multiple server hosts 104as shown by FIG. 12. The requests are forwarded to the various serverhosts by a server I/O program 1207.

[0052]FIG. 13 is a flowchart for the DB proxy architecture 101.Initially, as shown by step 1301, the DB proxy operator configures thedatabase information 1208 (see FIG. 14) to initialize the proxy setting.The DB proxy 101 receives a data search request from the host 1201 inwhatever desired message format is being employed, e.g., SQL, http,LDAP, etc. This is illustrated at step 1302. At step 1303 the DB proxy101 forwards the request to the multiple server hosts 104 as will bedescribed in conjunction with FIG. 15. The DB proxy 101 also receivesthe results from the multiple servers and sends them to the clienthosts, as illustrated by step 1304.

[0053]FIG. 14 is a diagram illustrating database access information.This is the information 1208 referred to above in conjunction with FIG.13. The database access information includes a server name 1401, aserver address 1402, a port number 1403, and original data locationinformation 1404. The server name column 1402 shows the server namedefinition which the DB proxy 101 uses as its target for forwarding datasearch requests. The server address 1402 is the IP address assigned toeach server, while the port number shows the type of data search serviceemployed by the server host, e.g., LDAP, SQL, etc. The original datalocation refers to the location of the primary site, for example asdepicted in FIG. 1.

[0054]FIG. 15 is a flowchart illustrating a search of multiple databasesusing the DB proxy architecture described above. Operations by the DBproxy are shown in the left-hand column, and by the server host in theright-hand column. Initially, the database search program 1206 (see FIG.12) at the DB proxy 101, converts the client request into a propermessage type as defined by the port number 1403 (see FIG. 14) in thedatabase access information. For example, the http request from client1201 must be converted into an LDAP request format to form anunderstandable request to the LDAP server, or into an SQL request formatto be understandable by the SQL server. This conversion operation isshown at step 1301, and is carried out using well known software. Atstep 1502, the DB proxy 101 issues the converted request to the properservers defined in the server address column 1402 and in the databaseaccess information 1208. As shown by the right-hand column of FIG. 15,the server host 104 receives this request from the DB proxy 101 in theproper message format 1503. The data management program 1206 at eachserver host 104 then begins to search the requested data stored in thatstorage system, using the host I/O program 311. This operation is shownat step 1504.

[0055] Next, as shown in step 1505, the server host 104 returns thesearch result to the DP proxy 101, which receives it at step 1506. Atstep 1507 the DB proxy 101 awaits replies from all servers 104 to assurethe results are complete. As shown at step 1508, once all results arereceived and complete, the proxy 101 merges the results into a singlemessage using the client I/O program 1205 (see FIG. 12).

[0056]FIG. 16 illustrates the overall operation of this system for onesample query. In the example, a client 1201 has sent a request to the DBproxy 101 requesting all individuals whose first name is Michael and whowork in the Sales Department in any office. The DB proxy 101 has dividedthat request into three appropriately formatted queries to access thethree hypothetical sites where this information would be maintained. Itaddresses server A 104A in LDAP format, server B 104B in SQL format, andserver C 104C in http format. Each of those servers queries itsassociated database using the data management program appropriate forthat query and returns information to the DB proxy 101 in response tothe query. As shown, server A has returned the names of two employees,and each of servers B and C returned the name of a single employee. TheDB proxy 101 then merges the collected information, as shown by table1601, and presents it back to the client 1201. In table 1601, the firstname, last name, department and email address for each employee isprovided. In addition, the location of the original site from which thatinformation was derived is also presented.

[0057] The preceding has been a description of a preferred embodiment ofthe invention. It will be appreciated that there are numerousapplications for the technology described. For example, largecorporations having many branches remotely situated from each other, inwhich each has its own storage system and manages data individually, canbe coordinated. Thus, a main office can collect distributed data into alarge single storage system. This enables employees at one office tohave complete access to all data in the system.

[0058] In another example, a central meteorological office can collectand manage weather information from thousands of observatories situatedall over the world, appropriately querying and retrieving informationrelating to weather conditions at each site. As another example, thesystem provides data redundancy enabling protection of data despitesystem crashes, natural disasters, etc., at various sites. Theseapplications are made possible in heterogeneous environments, usinglegacy systems, but are transparent to the operator.

[0059] The scope of the invention will be defined by the appendedclaims.

What is claimed is:
 1. A system for facilitating retrieval ofinformation in which a first system stores first data at a firstlocation and a second system stores second data at a second location,the first system and the second system being coupled together by anetwork, the system comprising: a terminal connected to retrieve datafrom the first system; at least one replication software program forcopying data from the second system to the first system; and a proxysystem operating at the first location to enable a user of the terminalto retrieve data from the second system which data have been copied tothe first system from the second system.
 2. A system as in claim 1wherein the replication software program comprises a mirroring program.3. A system as in claim 2 wherein the data comprises data from adatabase.
 4. A system for facilitating retrieval of informationcomprising:. a first system storing first data at a first location; asecond system storing second data at a second location; a third systemlocated at a third location remote to the first and second locations,but connected to the first and second locations by a network, from whichthird system an operator is to retrieve information; at least onereplication software program for copying data from the first system overthe network to the third system and for copying data from the secondsystem over the network to the third system; and a proxy systemoperating at the third location to enable a user of the third system toretrieve data from the third system which has been copied to the thirdlocation from the first system and from the second system.
 5. A systemas in claim 4 wherein each of the first data and second data comprisesdata stored in a database.
 6. A system for facilitating retrieval ofinformation stored in databases at different locations comprising: afirst system storing first database information at a first location andbeing coupled to a network, the first system having mirroring softwareto enable copying of the database information from the first system to aremote system at a remote location over the network; a second systemstoring second database information at a second location and beingcoupled to the network, the second system also having mirroring softwareto enable copying of the database information from the second system tothe remote system over the network; a proxy system operating on theremote system to enable a user of the remote system to retrieve datacopied from the first system and copied from the second system to theremote system.
 7. A system for facilitating retrieval of informationstored at a plurality of different remote locations which information iscopied from the remote locations to storage at a local site comprising:a terminal coupled to access the storage at the local site; and a proxyserver at the local site which accesses information copied to the localsite from the remote locations.
 8. A method of facilitating retrieval ofinformation stored at a plurality of different locations comprising: ateach of the plurality of locations, performing a data back-up operationto cause data at that location to be copied over a network to a firstlocation; providing a user coupled to the first location with a proxyserver to access the data backed up to that location; and using theproxy server at the first location, accessing the data stored at thefirst location.